都会|下图_通俗理解Kubernetes中的服务，搞懂后真香

篇首语：本文由编程笔记#小编为大家整理，主要介绍了通俗理解 Kubernetes 中的服务，搞懂后真香相关的知识，希望对你有一定的参考价值。

&＃x1f447;&＃x1f447;关注后回复 “进群” &＃xff0c;拉你进程序员交流群&＃x1f447;&＃x1f447;

作者丨inicho

原文链接&＃xff1a;

https://blog.csdn.net/qq_43280818/article/details/107164860

1. 复习 pod 相关核心结构

1.1 pod 结构

• pod 相当于一个容器&＃xff0c;pod 有独立的 ip 地址&＃xff0c;也有自己的 hostname&＃xff0c;利用 namespace 进行资源隔离&＃xff0c;相当于一个独立沙箱环境。

• pod 内部封装的是容器&＃xff0c;可以封装一个&＃xff0c;或者多个容器&＃xff08;通常是一组相关的容器&＃xff09;

1.2 pod 网络

• pod 有自己独立的 IP 地址

• pod 内部的容器之间是通过 localhost 进行访问

2. pod 如何对外提供访问

首先 pod 有自己的 IP 和 hostname&＃xff0c;但 pod 是虚拟的资源对象 (在计算机中表现为进程)&＃xff0c;没有对应实体 (物理机&＃xff0c;物理网卡) 与之对应&＃xff0c;所以是无法直接对外提供服务访问的。

因此如果 pod 想对外提供服务&＃xff0c;必须绑定物理机端口 (即在物理机上开启端口&＃xff0c;让这个端口和 pod 的端口进行映射)&＃xff0c;这样就可以通过物理机进行数据包的转发。

下面以一台 Linux 系统的机器为例子&＃xff08; logstash 是做日志收集用的&＃xff09;

3. pod 的负载均衡

很关键的一个问题&＃xff1a;一组相关的 pod 副本&＃xff0c;如何实现访问负载均衡&＃xff1f;就如当请求达到&＃xff0c;请求转发给哪个 pod 比较好&＃xff1f;

一个想法就是用 pod 再部署一个 nginx。

举例&＃xff1a;如下图&＃xff0c;注意下图右边的 Node 里面有两个是 支付 服务&＃xff0c;与订单服务的是不同类型的 pod。如果一个请求订单的服务发来上面那个 Nginx&＃xff0c;那这个 pod 可以有 4 条转发路线&＃xff0c;可以想到用 hash 呀什么的把不同请求映射到不同的 pod 去转发。但能不能这么做呢&＃xff1f;

思考&＃xff1a;pod 是一个进程&＃xff0c;是有生命周期的&＃xff0c;一旦宕机、版本更新都会创建新的 pod&＃xff08; IP 地址会变化&＃xff0c;hostname 会变化&＃xff09;&＃xff0c;此时再使用 Nginx 做负载均衡不太合适&＃xff0c;因为它不知道 pod 发生了改变&＃xff0c;那请求就不能被接受了。所以服务发生了变化它根本不知道&＃xff0c;Nginx 无法发现服务&＃xff0c;不能用 Nginx 做负载均衡。那该如何实现呢&＃xff1f;使用 Service 资源对象。

3.1 什么是 Service 资源对象

• POD IP&＃xff1a;pod 的 IP 地址

• NODE IP&＃xff1a;物理机的 IP 地址

• cluster IP&＃xff1a;虚拟 IP&＃xff0c;是由 kubernetes 抽象出的 service 对象&＃xff0c;这个 service 对象就是一个 VIP (virtual IP, VIP) 的资源对象

3.2 service 如何实现负载均衡

例如现在要负载均衡地访问一组相同的服务副本——订单&＃xff0c;这时就要去做一个 service&＃xff0c;对外表现出是一个进程或资源对象&＃xff0c;有虚拟的 IP (VIP) 和端口。请求会访问 service&＃xff0c;然后 service 自己会 负载均衡 地发送给相应服务的 POD&＃xff0c;也就是下图中 4 个相同的 pod。

3.3 深入 service VIP

• service 和 pod 都是一个进程&＃xff0c;都是虚拟的&＃xff0c;因此实际上 service 也不能对外网提供服务

• service 和 pod 之间可以直接进行通信&＃xff0c;它们的通信属于局域网通信

• 负载策略&＃xff1a;把请求交给 service 后&＃xff0c;service 使用 iptables&＃xff0c;ipvs 来实现数据包的分发

而要对外网提供服务&＃xff0c;首先需要和之前一样 在物理机上也绑定一个端口 来接受访问请求&＃xff0c;然后把请求转发给 service&＃xff0c;service 再把数据包分发给相应的 POD。访问流程如下图所示&＃xff1a;

思考1&＃xff1a;那 service 对象是如何和 pod 进行关联的呢&＃xff1f;

它们之间的关联利用的 还是标签选择器 selector。且service 只能对 一组相同的副本 提供服务&＃xff0c;不能跨组提供服务。如果有另一组&＃xff0c;需要再创建一个 service。因此不同的业务会有不同的 service。

举例&＃xff1a;service 和 一组 pod 副本是通过标签选择器进行关联的&＃xff0c;相同的副本的标签是一样的。

selector&＃xff1a;app &＃61; x 选择一组订单的服务的 pod&＃xff0c;创建一个 service&＃xff1b;app &＃61; y 选择了一组支付的服务的 pod。通过一个 endpoints 属性存储这组 pod 的 IP 地址&＃xff0c;这样就有了映射关系了 (关联起来)。

思考2&＃xff1a;pod 宕机或发布新版本了&＃xff0c;service 是如何发现 pod 已经发生变化的&＃xff1f;

通过 k8s 中的一个组件 —— kube-proxy (第 1 篇有提到过)&＃xff0c;每个 NODE 里都运行着这个服务。它需要做的工作如下图右侧&＃xff1a;

service 实现服务的发现&＃xff1a;kube-proxy 监控 pod&＃xff0c;一旦发现 pod 服务变化&＃xff0c;将会把新的 ip 地址更新到 service。

注意&＃xff1a;endpoints 那些都是存储在 etcd 里的 (也是第 1 篇提到过的)&＃xff0c;所以 kube-proxy 更新的存储在 etcd 里的映射关系。

————————————————

版权声明&＃xff1a;本文为CSDN博主「inicho」的原创文章&＃xff0c;遵循CC 4.0 BY-SA版权协议&＃xff0c;转载请附上原文出处链接及本声明。

原文链接&＃xff1a;

https://blog.csdn.net/qq_43280818/article/details/107164860

-End-

最近有一些小伙伴&＃xff0c;让我帮忙找一些 面试题 资料&＃xff0c;于是我翻遍了收藏的 5T 资料后&＃xff0c;汇总整理出来&＃xff0c;可以说是程序员面试必备&＃xff01;所有资料都整理到网盘了&＃xff0c;欢迎下载&＃xff01;

点击&＃x1f446;卡片&＃xff0c;关注后回复【面试题】即可获取

在看点这里好文分享给更多人↓↓